Ensure make -j uses a reasonable argument
#1541
Conversation
Co-authored-by: Hugo van Kemenade <[email protected]>
Co-authored-by: Hugo van Kemenade <[email protected]>
…imit on the number of concurrent jobs, not "a sensible limit considering the available memory and CPU cores". With LTO it's easy to run out of memory when too many jobs run at the same time.
|
Let's use |
| @@ -203,14 +203,13 @@ do to get a pydebug build of CPython. | |||
|
|
|||
| Once ``configure`` is done, you can then compile CPython with:: | |||
|
|
|||
| $ make -s -j2 | |||
There was a problem hiding this comment.
Note that nproc is part of GNU coreutils and may not necessarily be available on all Unix-like systems (namely, macOS). So Mac users should first do brew install coreutils or use sysctl instead to get the number of physical or logical cores (I don't remember which one nproc returns)
There was a problem hiding this comment.
I've merged, as Hugo uses macOS and didn't complain, but we can open a follow-up if need be.
There was a problem hiding this comment.
Thanks for pointing that out. I do have coreutils installed via Homebrew, which is why it worked for me. Let's not require or assume others do.
Shall we use a hardcoded value under the macOS tabs? Something like 8 feels like a good default?
There was a problem hiding this comment.
TL;DR - this is good enough.
I feel like people who understand how to run make already understand what $(nproc) can be substituted with manually if they don't have the command. if we wanted to be ironic we'd suggest $(python3 -c 'import os; print(os.cpu_count())') to the person who is building python and may not yet have a built python3 (but realistically do anyways because all Linux distros offer it and macOS xcode comes with one). 😛
There was a problem hiding this comment.
I feel like people who understand how to run
makealready understand what$(nproc)can be substituted with
That seems like a rash assumption to me; I would expect anyone with that level of comfort with make to not need to be walked through "run ./configure && make". There's also the point that make -j $(nproc) in the absense of a working nproc will leave the user with make -j , which is what we were trying to avoid with this change.
There was a problem hiding this comment.
The assumption would be correct if we were in the extension-modules.rst file, but this file is for the "getting started". I don't think we should assume that the reader is extra familiar with make and even knows about nproc and co (this section would be read by newcomers I think).
By the way, nproc being part of coreutils and not necessarily available on macOS caused some issues in other projects: https://www.drupal.org/project/drupal/issues/3407360. So it's not necessarily a theoretical use case.
📚 Documentation preview 📚: https://cpython-devguide--1541.org.readthedocs.build/